IBIS Macromodel Task Group Meeting date: 13 June 2023 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora Systems: Dian Yang Cadence Design Systems: * Ambrish Varma Jared James Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak * Kinger Cai Chi-te Chen * Liwei Zhao Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): * Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Siemens EDA (Mentor): * Arpad Muranyi * Randy Wolff Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Note: The meeting scheduled for June 6th was not held. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the May 30th meeting. Walter moved to approve the minutes. Michael seconded the motion. There were no objections. -------------- New Discussion: PSIJ Discussion: Walter noted that Bob had previously mentioned a recent IBIS Summit presentation on the topic. Bob said the presentation, from the Indian Institute of Technology Jodhpur, contained an alternate formulation that might be related to BIRD220. Bob said that he had reached out to the authors to see if they had any interest in commenting on BIRD220 or the PSIJ Sensitivity proposal from Kinger. Bob took an AR to send information about the presentation to the ATM list. AMI Support for [Test Data]/[Test Load]: Michael shared and reviewed draft1, which he had recently sent to the ATM list. He said [AMI Test Data] is designed to be analogous to the existing [Test Load] and [Test Data] keywords. The principles are the same, but the goal in this new proposal is to specify the load on the Tx (including the Rx), the stimulus, and the output waveform data the AMI simulation is expected to generate. Michael said the traditional [Test Load] is insufficient for AMI because its channel description capability is limited and inputs to an AMI simulation can not be described completely. He said that the new proposal's most dramatic difference from the existing keywords is that the waveform data is assumed to live in a separate file, as it is likely too long to be included inside the .ibs file itself. In addition, the input pattern and AMI parameter settings are specified. The channel specification in the new proposal provides a reference to an IBIS-ISS subcircuit. Walter presented a high-level summary of what he thought Michael was proposing that the EDA tool would do with this information: - Simulate the Tx IBIS model (analog portion of the AMI model) with an IBIS-ISS subcircuit, which may or may not have an AMI Rx model as a load at the end of the channel, to determine the step (impulse) response. - Once it has determined the impulse response, then it can call the Tx AMI_Init and Rx AMI_Init (if an Rx model exists). - If testing AMI_GetWave, the simulator calls the Tx AMI_GetWave with the specified bit pattern stimulus. The Tx AMI_GetWave returns a waveform, which the simulator then convolves with the impulse response. The resulting waveform is what gets compared to the test waveform data for a Tx. - The tool then passes the waveform to the Rx AMI_GetWave (if it exists) and the waveform returned by AMI_GetWave is what gets compared to the final test waveform. So, the test waveforms are the expected outputs of AMI_Init or AMI_Getwave for the Tx and or Rx. This proposal is testing the ability of the EDA tool to compute the step response, and it is also testing its ability to pass data in and out of the executable model. Michael said he largely agreed with this summary. However, he noted two important points. He said his proposal required an AMI Rx to be included, and he envisioned an end-to-end AMI simulation with no option for having anything other than an AMI Rx model at the end of the channel. He said if we need to open up the proposal for other combinations we will have to discuss it. He also noted that his proposal deliberately avoided any discussion of how to compare the waveforms. Ambrish said he thought it was problematic to include the EDA tool's computation of the impulse response in this process. He said the impulse response of the channel should be one of the specified inputs included in the test data. If that were done, then there would be no need to define the channel at all. The model maker would simply provide the initial impulse response that the EDA tool should pass through its AMI processing. As written, it leaves open all sorts of troublesome issues comparing impulse responses from different tools. Michael agreed that if we just want to test the algorithmic (executable model) processing, then we should specify the impulse response as an input. However, he said this would be ignoring one of the largest issues faced by model makers. The computation of the impulse response is where many users/tools run into trouble before they even get to AMI processing. Without testing the tool's impulse response, the model maker still wouldn't have a single solution that ensures their model is getting the right inputs and generating the right outputs. He said he was looking for a "one-button" solution for model makers to test the end-to-end flow. Fangyi agreed with Ambrish. He said there are three things we are discussing testing: analog AMI processing, executable model processing, and the tool's simulation of the impulse response. He said the first two can be tested separately with well defined initial conditions, such as Ambrish's suggestion that the impulse response be specified as an input. He said he didn't think we should be trying to test the third one at all, as this is the domain of the simulator. We shouldn't try to mandate what the tool does in calculating the impulse response. Ambrish said that if we remove the simulator specific part, i.e., the impulse response generation, from this proposal and simply provide an input IR, then perhaps the existing Test Load and Test Data keywords could be upgraded to work for AMI. Michael said he is coming from a model maker's perspective, and he is attempting to provide a simple one-step end-to-end test for the model maker. Fangyi said this issue is similar to that of a foundry producing a SPICE model. The foundry provides a SPICE model to the circuit designer, but the circuit designer then uses the SPICE model within their simulator of choice. Ambrish said that trying to define testing and comparison criteria for the tools' initial channel characterization would be a giant headache. He said it would be simpler to provide the impulse response as an input and perform black box testing of the AMI model. Once we achieve that first step, we could think about how to deal with channel characterization later. Michael said this would be kicking the biggest part of the problem down the road, and we will have to deal with it eventually. Fangyi asked how this proposal would work if the Tx and Rx models were not from the same model maker. Michael agreed that this was a good point. He said he was thinking about it purely from a model maker's perspective, and his proposal required a Tx and an Rx. However, for a user looking to use Tx and Rx models from different vendors this would be a problem. Michael said the proposal already has issue with having to provide models for structures that aren't part of the actual [Component], so there are tricky issues to resolve. Fangyi said that if we adopt Ambrish's proposal and provide the impulse response as an input, then we can test Tx and Rx devices independently. Arpad asked whether we want to leave open the option for BCI testing in the future. Randy and Fangyi said that we would also want a way to test the clock output (clock_times) of the Rx model. Michael agreed with these suggestions, and he noted that there are other complicating factors such as AMI parameter dependencies that he had not addressed in the first draft. Michael said he understood what Ambrish and Fangyi were proposing. We would include no channel model and instead provide an impulse response that the tool can pass to the AMI models. This would allow the Tx and Rx to be independently tested. It would give the tool the impulse response, the control settings, and the waveform the user should see at the output. He questioned whether the impulse response is accessible by the user in most tools. He said from a user's perspective, the impulse response portion of the processing may not be transparent. Ambrish and Curtis said that the impulse responses were easily accessible in their tools. Wei-hsing said that a model maker developing a model can choose to have a debug mode that captures the input impulse response the model receives from the tool. Wei-hsing said that during model development the model maker may not even have access to a full-blown simulator to generate the impulse response. So, they might use some small utility to feed an example impulse response to their model for testing. Fangyi agreed that this was a good point. He said a model maker is probably not running any simulator when they are writing their model. They likely develop and test the model with an example impulse response. Walter suggested that what the proposal aims to support can already be done with an EMD model today. One could create an EMD model containing Tx and Rx models with an IBIS-ISS subcircuit connecting them. The AMI models could be specified with default values for all of their parameters. The EDA tool could import that EMD model, run the simulations, and present the results (impulse responses, waveforms at various places, etc.). Michael agreed, but he said automation and ease of use are important. Walter said that this approach could be tried right now, and if it is useful, we could capture additional setup and automation details in a BIRD. Arpad suggested that the proposed syntax for specifying the values of the AMI parameters is insufficient if the same parameter name appears in multiple branches. Michael agreed that this was an issue he hadn't considered. Arpad asked whether we should just specify the exact parameter string to be passed to the model. Michael said his concern was that we would have to be very careful to make sure the model maker understands the syntax of the parameters string. Michael said he would work on improving this section of the proposal, as Arpad's concern was valid and needed to be addressed. - Michael: Motion to adjourn. - Walter: Second. - Arpad: Thank you all for joining. New ARs: Bob: Send information about the recent IEEE SPI IBIS Summit presentation on PSIJ to the ATM list. ------------- Next meeting: 20 Jun 2023 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives